GitLab.com 是一個功能強大基於 Web 的工具（也有 self-manage 的開源版本），在 GitLab.com 上主要能幫助團隊協作程式碼，你可以輕鬆地與團隊成員一起討論、修改複雜的技術專案，而不會陷入需要追蹤同一專案卻有多個版本，而無法管理的問題。GitLab 建立在 Git 版本控制系統上，所以可以便於版本控制。

關於版本控制或是 Git 的概念，究竟是什麼？你可以想像你有一份文件，有多個同事需要對這份文件做審核後修改，由於公司對於開一份 Google Doc 在上面同步編輯有所考量，所以你必須在個人電腦上先編輯這份文件，再以附檔的方式用 Email 寄出給幾位同事審核。這時候就會出現問題，A 同事修改了你寄出的文件後，發送 Email 給大家，但同時 B 同事也正在改你寄出的原始檔案，接著也寄出發送給大家，以此類推...過了一個晚上，你收到了 5 封基於你原始檔案而修改的 Email 文件，他們各自獨立，卻又有不同地方被重複修改。

那麼如何解決這種情況呢？通常團隊可能會安排會議來實際討論、完成這份文件，但聽起來有夠麻煩，你必須再聽一次這 5 個基於你原始檔案修改的文件，到底改了哪裡？還有要確定它們彼此到底哪裡重疊？

你可以把這樣的狀況套用在程式開發上，如果正在開發的工程師每 10、100、1000 行程式碼都有這樣獨立提交又有部份重疊的狀況，大家開會時再重看這些程式碼絕對會瘋掉。

而使用 GitLab（或是 Git），目的就是讓你可以直接在同一個空間(伺服器)上建立自己修改完的副本（在 Git 中稱為分支），等到更改滿意後，可以將其「合併」到最原始的檔案中。這個概念就會變成 A 同事、B 同事更改完最原始的文檔後，他們會各自在 GitLab 上會推一個基於原檔修改的副本，大家同時可以看到這些副本，可以看到它們各自與最原始檔案的差異以及哪些地方產生衝突需要修正，最後確認沒問題後，大家可以決定要「合併」哪份副本檔案，那份副本檔案就會覆蓋掉你原本寫的文檔，同步讓大家知道這是最新版本，之後幾個副本也是以此類推，必須要做到「合併」這個動作，才會是現在「最新的版本」，大家就會以這個最新版本為主，你也可以查看到哪份副本文件被合併到原始檔案之上了、修改了哪些地方，也可以知道最後是採用哪個人提出的副本以及現在修改的進度是如何。

在這裡我想強調下，這樣的版本協作絕對仍需要「手動」執行的部分，你還是要看過副本文件，知道誰改了什麼，再手動去做合併。在 Git 上面是以結構化的方式去操作，對於一般開發者而言是沒有問題的，但倘若 PM、設計師一起加入這個開發專案，就不見得這麼容易理解，而 GitLab 這個基於 Git 所開發的平台，可以讓工程師、非工程師同樣簡單且能理解的去執行版本控制，簡言之其實就是能更 UI 化的用 Web IDE 讓大家在 GitLab.com 上直接操作版本控制。

在 GitLab.com 上面基本上都是用 Markdown 這種直觀的文檔創建語言來做文件溝通，下一篇我會示範如何建立專案、編輯文件以及與團隊協作（包含合併版本、解決衝突等）。